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(54) Apparatus and method for integrated telecommunications 



(57) A telecommunications system includes a con- 
vergence protocol that provides direct inter- layer com- 
munications between nodes within the network. The 
transport layer of one network node may communicate 
directly with the service layer of another network node. 
The service layer may be configured as an internet pro- 
tocol (IP) layer, which may employ asynchronous trans- 
fer mode switching, and the transport layer may be a SO 



NET transport layer. Each of the nodes that runs the 
convergence protocol may be a telecommunications 
element such as an add-drop-multiplexer (ADM) or a 
digital cross connect. SONET bandwidth provisioning 
may be accomplished through the inter-element, inter- 
layer communications of the convergence protocol. 
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Description 

FIELD OF THE INVENTION 

[0001] The invention relates to telecommunications 
systems and, more particularly, to the integration of cir- 
cuit switched and packet switched telecommunications 
services. 

BACKGROUND OF THE INVENTION 

[0002] The explosive growth in the use of high- 
speed data transmission and the demand for differenti- 
ated data services strain the ability of existing telecom- 
munications systems, a somewhat awkward marriage of 
circuit switched and packet switched systems, to meet 
the surging demand, both today and into the future. 
Conventional data communications systems which 
employ the publicly switched telephone network com- 
bine circuit switched TDM-based transport with best- 
effort packet switching, such as internet protocol (IP) 
switching, to effect data transmission in a manner that 
emphasizes maximum link utilization. 
[0003] Telecommunications links may be estab- 
lished in a number of ways, with different advantages 
accruing to different methods of connection. The direct 
connection of two or more channels between two instru- 
ments, a connection that provides a user with exclusive 
use of the channels to exchange information, is referred 
to as a circuit switched, or line switched, connection. 
Circuit switching is a technique which yields highly reli- 
able service and is particularly suitable for such "real 
time" communications applications as voice, in which 
the momentary loss of a channel is annoying, and 
repeated such losses are unacceptable. Circuit switch- 
ing is also employed for highly reliable leased-line serv- 
ices. Electronic switching systems, such as the 5ESS 
may interconnect a multitude of telephone instruments 
through circuit switching, employing time division multi- 
plexing (TDM), for example. In orderto ensure that end- 
users receive the appropriate quality of service, the 
switches typically monitor and periodically test the activ- 
ity of the trunk lines that carry the channels being 
switched. If a communications error occurs, the switch 
may employ a "loopback" to isolate, or determine the 
exact location of, the system component that caused 
the error. Once the failure is isolated , the system may 
reconfigure itself so that data may be routed around the 
failed system component, through a loopback, or take 
other corrective measures. TDM transport networks 
provide an assured level of performance and reliability. 
Technologies, such as Synchronous Optical Net- 
work/Synchronous Digital Hierarchy (SDH/SONET) 
may be employed in the transport infrastructure to pro- 
vide high-capacity transport, scalable to gigabit per sec- 
ond rates, with excellent jitter, wander, and error 
performance for voice connections and leased-line 
applications. SONET/SDH self-healing rings enable 



service-level recovery within tens of milliseconds follow- 
ing network failures. 

[0004] Packet switching may be employed to maxi- 
mize the utilization of telecommunications links, such as 

5 leased circuit-switched lines. With the packet switching 
approach, data is transmitted in packets, and the com- 
munications channel is only occupied for the duration of 
a packet's transmission. After the transmission, the 
channel is available for use by packets being transferred 

w between other instruments. The links are statistically 
mutliplexed to achieve maximum link utilization and are 
typically carried on leased circuits through the TDM 
transport network. Packet-switched systems often 
employ Internet Protocol (IP) transport methods to route 

15 packets from a source to a destination. Such systems 
generally employ "best-effort" techniques to deliver the 
packets and they generally lack the means to guarantee 
high reliability and predictable performance. Although 
statistical multiplexing yields high link utilization, the 

20 best-effort service provided by IP data networks is 
accompanied by unpredictable delay, jitter, and packet 
loss. 

[0005] Although existing IP data networks provide 
excellent connectivity, they do not enable controllable 

25 distribution of network resources among the various 
service providers employing the IP data network to pro- 
vide data transmission services to end users. That is, 
through a provisioning process that typically requires 
the intervention of craft workers, a process that takes 

30 place relatively infrequently, the TDM-based transport 
services provide fixed bandwidth communications 
channels for each service provider. Since packet data 
traffic is inherently irregular, with bursts of heavy utiliza- 
tion followed by periods of relative inactivity, the fixed 

35 bandwidth "pipes" of TDM transport limit the flexibility 
with which transport users, such as IP data transport 
service providers, can respond to variation in demand 
from their end-users. Service providers must rely upon 
the good behavior of end users, who must scale back 

40 their transmissions during periods of heavy congestion. 
The well-known "tragedy of the commons" teaches that 
such reliance on the cooperative good behavior of a 
large group of users may not be a reasonable approach 
in the long run. This is made particularly clear in light of 

45 some applications, such as streaming video, that tend 
not to cooperate in scaling back traffic during periods of 
high usage. 

[0006] Additionally, since the service layer and 
transport layer are separated in such a multi-layered 

so dual architecture (circuit switched transport/IP) telecom- 
munications system, transport management is segre- 
gated into separate operation and maintenance 
functions. In turn, this segregation of operations and 
maintenance functions generally requires the coordina- 

55 tion of separate organizations and renders the process 
of end-to-end provisioning of a channel a difficult task. 
Such provisioning requires an inordinate amount of 
expertise and time, complicates the task of traffic engi- 
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neering, and, as a result, the quality of service suffers 
while, at the same time, the transport core is underuti- 
lized. 

[0007] A system and method which provide network 
infrastructure support to provide differentiated service 5 
guarantees and corresponding service level agree- 
ments to service providers, while taking advantage of 
both the high quality of service provided by circuit 
switched systems and the high utilization afforded by 
packet switched systems, would be highly desirable, w 
Additionally, it would be highly desirable for such a sys- 
tem to dramatically increase, and maximally share, 
backbone network infrastructure capacity, and provide 
sophisticated service differentiation for emerging data 
applications, at least in part by dynamically managing 15 
the transport core bandwidth. 

[0008] In short, a system which exploits the fast res- 
toration, proven stability, low cost and low transport 
latency of SONET/SDH transport networks and bridges 
the gap between SONET/SDH transport and IP trans- 20 
port to thereby minimize operation cost and facilitate 
traffic engineering, would be highly desirable. 

SUMMARY 

25 

[0009] A telecommunications system in accordance 
with the principles of the present invention includes a 
convergence protocol that provides efficient inter-layer 
communications between nodes within the network. For 
example, the convergence protocol permits the trans- 30 
port layer of one network node to communicate directly 
with the service layer of another network node. In an 
illustrative embodiment, the service layer is configured 
as an internet protocol (IP) layer, which may employ 
asynchronous transfer mode switching, and the trans- 35 
port layer is a SONET transport layer. Each of the nodes 
may be a telecommunications element such as an add- 
drop-multiplexers (ADM) or a digital cross connect, for 
example. This inter-layer communication is achieved 
through a layer- 1 pass through operation. 40 
[0010] In one aspect of the invention, SONET band- 
width provisioning, which heretofore has been static, is 
rendered flexible. Additionally, the division between 
transport and service is eliminated. This increased flex- 
ibility, in turn, provides support for differentiated service 45 
guarantees and corresponding service level agree- 
ments. The system provides the high quality of service 
typical of circuit switched systems, and, at the same 
time, features the high utilization of a packet switched 
system. A system in accordance with the principles of so 
the present invention merges IP transport and 
SONET/SDH transport through a novel convergence 
protocol. The flexibility provided by this approach per- 
mits dynamic management of a link's internal transport 
bandwidth thereby accommodating bursty traffic at min- 55 
imal cost, with little end-to-end latency. For example, 
given one channelized interface, such as a 40C12C 
based OC48 link, with conventional static provisioning 



the termination of each tributary is fixed for extended 
periods, often months. But, in accordance with the prin- 
ciples of the present invention, the termination point of a 
tributary may be dynamically altered to accommodate a 
service provider's run-time needs. Consequently, the 
potential re-configuration period may be reduced from 
months to minutes, or even seconds. 
[0011] In accordance with the principles of the 
present invention a communications network employs a 
protocol hereinafter referred to as the convergence pro- 
tocol, which encapsulates the SONET/SDH transport 
details and which permits internal bandwidth to be man- 
aged on the fly to accommodate varying service 
demands. As a result, in general, data service providers 
need no concern themselves with the internal details of 
transport network infrastructure because of the smooth 
interface between external Internet backbone and 
SONET/SDH transport backbone. The SONET/SDH 
transport backbone may adaptively rearrange its inter- 
nal bandwidth thus permitting automated end-to-end 
provisioning. One or more network elements are config- 
ured as core access points (CAPs) to provide an inter- 
face between SONET/SDH transport and external IP 
transport. 

BRIEF DESCRIPTION OF THE DRAWINGS 

[0012] The above and further features, aspects, 
and advantages of the invention will be apparent to 
those skilled in the art from the following detailed 
description, taken together with the accompanying 
drawings in which: 

Figure 1 is a conceptual block diagram of a commu- 
nications network in accordance with the principles 
of the present invention; 

Figure 2 is a conceptual block diagram of a network 
element in accordance with the principles of the 
present invention; 

Figure 3 is block diagram of a communications net- 
work in accordance with the principles of the 
present invention; 

Figure 4 is a diagram of a protocol data unit in 
accordance with the principles of the new conver- 
gence data protocol; 

Figure 5 is a block diagram illustration of a conven- 
tional IS-IS level2LSP; 

Figure 6 is a block diagram illustration of a conven- 
tional IS-IS variable field length field; 

Figure 7 is a diagram of an enhanced IS-IS level 2 
LSP in accordance with the principles of the 
present invention; 
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Figure 8 is a binding table diagram in accordance 
with the principles of the present invention; 

Figure 9 is a path table diagram in accordance with 
the principles of the present invention; 5 

Figure 1 0 is a header entry table diagram in accord- 
ance with the principles of the present invention; 

Figure 11 is a status table diagram in accordance w 
with the principles of the present invention; 

Figure 12 is a conceptual block diagram of a com- 
munications system Which employs a convergence 
protocol in accordance with the principles of the is 
present invention; and 

Figure 13 is a scenario diagram of a bandwidth allo- 
cation process in accordance with the principles of 
the present invention. 20 



DETAILED DESCRIPTION 

[001 3] In the conceptual block diagram of Figure 1 a 
telecommunications system 100 including both packet 25 
switched and circuit switched components operates in 
accordance with the principles of the present invention. 
At the transport layer one or more SONET/SDH network 
elements (NE1 , NE2, and NE3 in this illustrative embod- 
iment) provide the circuit-switched cross connect for 30 
packet switched devices such as internet protocol (IP) 
device 104, asynchronous transfer mode (ATM) device 
106, and and ATM device 108. The IP device 104 and 
ATM devices 1 06 and 1 08 may be a combination of one 
or more devices that could be arranged in a ring topol- 35 
ogy for example. The system 100 is shown with only a 
limited number of devices in order to simplify the expo- 
sition and understanding of the invention. Two cross- 
connect paths, 1 10 and 112, between the IP device 104 
and ATM device 1 06 and between the I P device 1 04 and 40 
the ATM device 108, respectively, provide the specific 
circuit switched paths across the SONET/SDH transport 
layer. Each path may transit a plurality of SONET/SDH 
network elements and may share the bandwidth 
through each of those elements with other paths not 45 
shown in Figure 1. A service provider may provision a 
portion of the bandwidth on each of the paths 110 and 
112 for use by customers who wish to transmit data 
between the IP device 104 and the ATM device 106 and 
between the IP device 104 and the ATM device 108, for 50 
example. 

[0014] The layers discussed hereinafter refer to OS I 
layers, which are known and discussed, for example, by 
Ming-Chwan Chow, "Understanding SONET/SDH" 
ANDAN Publisher, Holmdel, NJ pages 2-31 through 2- 55 
32, which is hereby incorporated by reference. Unlike 
conventional systems in which inter-layer communica- 
tions are restricted to intra-element communications, a 



telecommunications system in accordance with the 
present invention may perform inter- layer communica- 
tions between network elements. That is, the service 
layer of a network element such as NE1 may communi- 
cate with the transport layer of network element NE2. 
As will be described in greater derail below, this commu- 
nications path permits a network in accordance with the 
principles of the present invention to re-provision the 
paths 110 and 112 to accommodate changing band- 
width demand along the paths. This is in contrast with a 
conventional system wherein the provisioning is static 
and manual. That is, in a conventional system, a service 
provider, such as AOL, would have to request re-provi- 
sioning by the transport service provider, such as AT&T, 
and which would require the intervention of craft work- 
ers. Such re-provisioning and would typically take place 
only a few times each year. 

[0015] In accordance with the principles of the 
invention if, for example, the path 1 10 is provisioned for 
a given transmission rate and a surge in demand occurs 
for the link between NE1 and NE2, the network element 
NE1 may directly request of the network element NE3 
sufficient bandwidth to supply data to NE2 along paths 
112 and 113 from NE1 to NE2. This immediate provi- 
sioning is accomplished through a direct inter-layer and 
inter-element communications in the direct communica- 
tions channel (DCC) as described in greater detail 
below. 

[0016] Each of the network elements NE1, NE2, 
and NE3, of Figure 1 could operate as a CAP, thereby 
permitting SONET transport for packet-switched net- 
works such as those which employ Internet Protocol. A 
front-end aggregating router may be consolidated with 
an entry CAP, so packet level traffic may be served by 
an entry CAP. Additionally, because each CAP has the 
capability to monitor both layer-3 and layer-1 opera- 
tions, each CAP also has the ability to re-arrange the 
size of individual logical-pipes "on the fly" (through 
exchanging Convergence Protocol message with other 
nodes). Consequently, the inventive system can adap- 
tively adjust the bandwidth to optimize pipe-utilization, 
and, at the same time, improve service for best effort 
delivery traffic based on each CAP'S performance mon- 
itoring. It may also adjust the bandwidth arrangement 
based on input from a centralized network management 
system which collects the global network traffic statis- 
tics. 

[0017] The conceptual block diagram of Figure 2 
illustrates the interconnections between the packet- 
switched 202 and circuit switched 204 components of a 
network element 200 in accordance with the principles 
of the present invention. The packet-switched compo- 
nent 202 includes an internet protocol and asynchro- 
nous transfer mode switch 206 that is operatively 
connected to line cards 208 and 210. The line cards 208 
and 210 are connected through SONET links 212 to the 
circuit switched section 204 through the circuit switched 
Input/output 214 of a circuit switched shelf 216. The cir- 
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cuit switched section 202 may include a plurality of local 
switch fabrics, or circuit switched shelves, such as fab- 
rics 216. 218 and 220. Each of the fabrics may include 
I/O, such as I/O 214 and 216 of the fabric 216, a local 
switch core 222, shelf control 224, and an interface 226. 5 
The interface 226 provides communications between 
the local switch fabric and a central switch fabric 228. 
The central switch fabric 228 includes shelf control 230, 
an interface 232 for each of the local fabrics, and a cen- 
tral switch core 234. ?o 
[0018] A network element such as the network ele- 
ment 200 of Figure 2 may be employed as an interface 
between circuits switched and packet switched net- 
works. When the network element is used in this man- 
ner, it will be referred to as a core access point, 15 
hereinafter. The network 300 illustrated in the concep- 
tual block diagram of Figure 3 includes core access 
points 302 and 304 which provide an interface between 
the IP transmissions of elements 306 and 308 and the 
SONET transport of elements 310, 312, 314, and 316. 20 
That is, transmissions among the network elements 
310, 312, 314, 316, 302, and 304 are SONET/SDH 
transport transmissions, and transmissions among net- 
work elements 302, 304, 306, 307, and 308 are IP 
transmissions. 25 
[0019] In accordance with the principles of the 
present invention, network elements that operate as 
core access points do so in conjunction with a new pro- 
tocol that will be referred to hereinafter as the "conver- 
gence protocol". The convergence protocol 30 
encapsulates the OS I stack. The convergence protocol 
data unit format is illustrated in Figure 4. The data unit 
comprises a five byte header and variable length fields. 
The header includes a one-byte convergence protocol 
discriminator, a one -byte length indicator, one byte that 35 
is split between length indication and version number, a 
one-byte protocol data unit type indicator, and a check- 
sum. Each protocol stack has its own layer structure. 
For example, in OSI there are seven layers: Physical, 
Link, Network, Transport, Session, Presentation, and 40 
Application. In this illustrative embodiment, the new pro- 
tocol is positioned at the Application layer and the length 
indicator indicates the total length of the associated pro- 
tocol data unit (PDU), in bytes. This number may not 
exceed 4K in this illustrative embodiment. The PDU 45 
type indicator may be used to denote any one of 256 
PDU types, each of which has its own format associated 
with it. The checksum byte is stores the checksum for 
the PDU. 

[0020] As noted, the PDU may be any of 256 types, 50 
including: 

PDU Type: 00000000 Function: Path 

Caching 

55 

[0021] The corresponding Variable Length Fields 
include the following: 



8 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: 
20 bytes 

The 1 st intermediate node NSAP address: 
20 bytes 



The k th intermediate node NSAP address: 
20 bytes 



The last intermediate node NSAP address: 
20 bytes 

PDU Type: 00000001 Function: Path 

Caching Confirmation 

[0022] The corresponding Variable Length Fields 
include the following: 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: 
20 bytes 
Response value: 
1 byte 

(Value: YES = 1 / NO = 0) 

PDU Type: 00000002 Function: Path 

Removal 

[0023] The corresponding Variable Length Fields 
include the following: 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: 
20 bytes 

PDU Type: 

00000003 Function: Bandwidth 

Allocation 

[0024] The corresponding Variable Length Fields 
include the following: 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: 
20 bytes 

No. of STS-1 Slots: 
1 byte 

STS-1 Slot No.: 

length determined by previous field 
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PDU Type: 

00000004 Function: Bandwidth 
Allocation Confirmation 

[0025] The corresponding Variable Length Fields 5 
include the following: 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: w 
20 bytes 
Response value: 
1 byte 

(YES = 1 / NO = 0) 

15 

PDU Type: 

00000005 Function: Bandwidth De- 
allocation 

[0026] The corresponding Variable Length Fields 20 
include the following: 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: 25 
20 bytes 

No. of STS-1 Slots: 
1 byte 

STS-1 Slot No.: 

length determined by previous field 30 
PDU Type: 

00000006 Function: Tunneled OSPF 

[0027] The corresponding Variable Length Fields 35 
includes the following header: 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: 40 
20 bytes 

[0028] With original OSPF message which includes 
the following five type messages: 

45 

Hello 

Database Description 
Link State Request 
Link State Update 

Link State Ack 50 

Note: The assumption is that OSPF-2 is supported. 
OSPF-2 is discussed, for example, in J.Moy, "OSPF 
R2.0, IETF RFC2328, ftp://ftp.isi.edu/in- 
notes/rf c2328.txt April 1998, which is hereby incorpo- 55 
rated by reference in its entirety. 



PDU Type: 

00000007 Function: Tunneled MPLS 
LDP 

[0029] The corresponding Variable Length Fields 
includes the following header message: 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: 
20 bytes 

with the original LDP message which includes the fol- 
lowing five type messages: 

LDP-REQUEST: Label Request Message 
LDP-MAPPING: Label Mapping Message 
LDP-WITHDRAW:Label Withdraw Message 
LDP-RELEASE: Label Release Message 
LDP-NAK: LDP Notification 

PDU Type: 

00000008 Function: Tunneled MPLS 
CRLDP 

[0030] The corresponding Variable Length Fields 
includes the following header message: 

Source node NSAP address: 
20 bytes 

Destination node NSAP address: 
20 bytes 

with the original constrained based routing label distri- 
bution protocol (CRLDP) message which includes the 
following messages: 

CRLDP-REQUEST: Label Request Message 
CRLDP-MAPPING:Label Mapping Message 

[0031] In this illustrative embodiment, the Label 
Withdraw, Label Release and Label Notification mes- 
sages used in LDP may be used for CRLDP directly. 
[0032] As previously mentioned the invention may 
be employed using SONET or SDH. For the conven- 
ience and clarity of exposition, the following exemplary 
embodiments will be described in terms of SONET, 
using SONET-related terminology, such as STS-N, but 
may be extended to SDH embodiments by one of ordi- 
nary skill in the art. 

1. Initialization 

1.1 Intermediate System-Intermediate System (IS-IS) 
based topology Auto-discovery: 

[0033] At initialization, assuming each CAP node 
has been provisioned with network service access point 
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(NSAP) address and IP address, the CAP node runs 
both OS I stack and TCP/IP stack. Correspondingly, 
each core intermediate point (CIP) node (a 
SONET/SDH network element that is strictly digital 
cross-connect system (DCS) and serves as part of 5 
SONET/SDH transport) is provisioned with NSAP 
address, and runs only OSI stack. With Level 2 IS-IS 
supported, multiple-area based infrastructure is sup- 
ported and the full 20-byte NSAP is used. Any variety of 
physical network topology, such as single-ring, ring- io 
based mesh inter-connection, mesh based topology, 
etc., may be employed with the new, convergence, pro- 
tocol. In one aspect of the invention the topology of this 
virtual autonomous system may be auto-discovered by 
establishing the IS-IS adjacency relationship based on 75 
an exchange of IS-IS HELLO message, then, establish- 
ing the physical topology of each node, including CAP 
and CIP, based on the exchange of IS-IS Link State 
PDU (LSP). 

20 

1.2 CAP path establishment 

[0034] Each CAP node serves as gateway for this 
virtual autonomous system. Each CAP establishes 
neighbor relationships with external routing neighbors 25 
through either an interior gateway protocol (IGP) or 
exterior gateway protocol (EGP) routing message. After 
establishing neighbor relationships, the CAP then 
obtains external route reachability information through a 
routing update message. Each CAP pair establishes an 30 
internal logical path. That is, although there may be one 
or more intermediate nodes between CAPs each CAP 
establishes the logical path to the other CAP by discov- 
ering the other CAP's node address. To establish the 
logical path, IS-IS communication is enhanced as fol- 35 
lows. Conventional IS-IS communication is described 
in, "Intermediate System To Intermediate System Intra- 
domain Routing Exchange Protocol For Use In Con- 
junction With The Protocol For Providing The Connec- 
tionless-mode Network Service (IS08473)", ISO DP 40 
10589, which is hereby incorporated by reference in its 
entirety. Conventional IS-IS Level 2 LSP exhibits the for- 
mat illustrated in Figure 5. 

[0035] In accordance with the principles of the 
present invention, the format of Figure 5 is employed, 45 
thereby maintaining compatibility with the existing IS-IS 
stack. However, the Variable Length Fields are 
expanded so that each CAP can flood its IP address 
information to the other CAPs based on IS-IS LSP 
update. 50 
[0036] The IS-IS level 2 LSP Variable Length Field 
format is illustrated in the diagram of Figure 6, in which 
one byte describes the code, one byte describes the 
length of the field and the remainder, the value. 
[0037] In accordance with the principles of the 55 
present invention, two CODEs, CODE 15 and CODE 
16, are used to support IP-V4 and IP-V6 address 
announcement, as illustrated in the enhanced IS-IS 



level 2 LSP variable length field diagram of Figure 7. 
CODE 15 is used to advertise IP-V4 address and 
CODE 16 is used to advertise IP-V6 address. During 
the period of IS-IS LSP update, each CAP will advertise 
its management IP address (either IP-V4 or IP-V6) 
based on enhanced IS-IS LSP, and each CIP will ignore 
the enhanced IS-IS LSP field. In response to the recep- 
tion of an enhanced IS-IS LSP a CIP will process the 
PDU conventionally; a CAP will additionally refresh its 
routing table, based on the incoming information, If the 
incoming data includes a new IP address, the CAP adds 
a new entry to its address binding table, as indicated in 
the binding table diagram of Figure 8. If the new 
addressed received by a CAP is the address of another 
CAP, the process, in which the assumption is that each 
CAP will only advertise its IP management address to 
another CAP, proceeds as follows: 

PROCESS 1, Logical Path Establishment: 

(Denoting the current node as A, which just received IP 
address from another CAP node: B) 

[0038] 

Step 1 : Find the senders NSAP address associated 
with IP address of node B 

Step 2: Discover the physical path between A and B 
based on IS-IS routing table look-up, record 
the path information 

Step 3: Send the Convergence Protocol Path Cach- 
ing message down this physical path, inside 
this message, source node is A, destination 
node is B, it also contains the NSAP 
address of intermediate nodes. 

Step 4: For each node along the path, after receiv- 
ing such Path Caching message, refresh its 
path information table: if there is no entry 
between A and B so far, add new entry; oth- 
erwise fill next node's NSAP information in 
the corresponding entry. Each entry of this 
path table should be of the format illustrated 
in the path table diagram of Figure 9. 

Step 5: Determine whether it's the final destination 
or not: 

If NO, strip its own NSAP address from 
Path Caching message, and pass this 
modified message to next node. 

If YES, record that it has received path 
information from Source A. Double 
check whether it has a path to reach A: 
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If YES, send the Path Confirmation 
message back to Source A. 

If No, based on A's NSAP address 
as contained in the received mes- 5 
sage, generate physical path to 
reach A based on IS-IS routing 
table look-up, send its own Path 
Caching message to A (source 
node is B, destination node is A, it w 
also contains the NSAP address of 
intermediate nodes), then send 
Path Confirmation message back 
to Source A. 

15 

Note: In this case, each intermedi- 
ate node is guaranteed to receive 
path information from B to A first, 
then process (forward) Path Confir- 
mation message received later. 20 

[0039] Through the above process, each CAP not 
only establishes its own address binding table, but also 
obtains the path information to reach the other CAPs. 
[0040] In accordance with the principles of the 25 
present invention, statically-provisioned internet chan- 
nels are used to satisfy bursty-traffic through a dynamic 
bandwidth management mechanism. The dynamic 
bandwidth management mechanism includes resource 
management structures, such as a new header table 30 
and status table, and processes that a CAP may use to 
respond to various bandwidth requests. The mecha- 
nisms and processes used to provide dynamic band- 
width management will be discussed in greater detail in 
relation to Figures 1 0 and 11. 35 
[0041] For both CAP and CIP nodes, there is 
resource table associated with each link in case one 
physical link is associated with one wavelength. In case 
WDM is deployed, there is resource table entry associ- 
ated with each X. The attribute of this resource table 40 
includes the address information of its neighbor, and the 
physical status of each of its STS-1 tributaries, here 
assuming the SONET network element is equipped with 
STS-1 level cross-connect capacity. 

[0042] This treatment of resource tables makes the 45 
new protocol suitable for application with single wave- 
length based optics (such as nowadays' SONET/SDH) 
and with multiple wavelength based optics. In the 1st 
case, each link is associated with one entry at resource 
Header Table, and in the 2nd case each wavelength is 50 
associated with one entry at resource Header Table. 
[0043] The header information for each node is 
organized as a table, as illustrated in Figure 10, and 
each entry in this table is associated with one link or 
associated with one wavelength. The format for each 55 
entry is illustrated in Figure 10. For each entry in this 
table, at initialization time, NSAP address field is provi- 
sioned as the neighbor's NSAP address, the Available 



Bandwidth field is provisioned as the physical capacity 
of this link/wavelength, or the number of STS-1 it can 
support. And STS-1 Array Pointer is initialized at run- 
time which points to the physical starting address of cor- 
responding STS-1 array associated with this header 
table entry. 

[0044] A Convergence Protocol based transport 
network in accordance with the principles of the present 
invention may employ equipment is compatible with and 
existing SONET equipment. Consequently, the existing 
SONET restoration approach such as UPSR and BLSR 
can be directly applied. Additionally, with a routing/LSR 
function in each CAP, the latest MPLS based restoration 
approach may also be used if an end-user prefers pro- 
tection granularity at IP flow level instead of SONET 
path/line level. So in general, the new transport network 
architecture offers a variety of protection switching solu- 
tions. 

[0045] The format of STS-1 Status Table entry is 
illustrated in the diagram of Figure 11, in which "Free 
Status" indicates whether this STS-1 slot has been allo- 
cated, the destination NSAP Address indicates what's 
the corresponding destination address for this tributary, 
and Available Bandwidth indicates the available band- 
width inside this STS-1 slot. 

[0046] In accordance with the principles of the 
present invention, at run -time each CAP may receive 
various formats of Bandwidth Request, which may 
come explicitly from service provider through SNMP 
command, or implicitly from MPLS label switching path 
setup process. These requests may be classified into 
two different categories: bandwidth allocation and band- 
width de-allocation. Associated with each request, infor- 
mation including IP Destination Address and bandwidth 
is provided. In response, a CAP in accordance with the 
principles of the present invention may allocate or de- 
allocate bandwidth as described below. Either of the 
described processes may be used to serve as an 
explicit SNMP provisioning command Additionally, 
either process may be used to support dynamic alloca- 
tion. The dynamic allocation may be used to support 
applications such as MPLS explicit routing, for example. 

STS-1 level bandwidth dynamic-allocation: 

[0047] Note: here the bandwidth requirement 
should be N times of STS-1 . 

PROCESS 2: 

[0048] For initiating a CAP nodeA: 

Step 1 : Receive IP destination address. 

Step2: Find corresponding NSAP address through 
Address Binding Table. Then based on Path 
Table, find the physical path to reach the 
next CAP. 
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Step3: Find next intermediate node's NSAP 
address based on information obtained 
from Path Table, Denote it as node B, Check 
the resource Header Table to find out the 
link which satisfies the following conditions: 

The Neighbor of this link is B 

The available bandwidth for this link 
exceeds the bandwidth as required 

If there is no such link, Respond NO. 

Step4: Send Convergence Protocol Bandwidth 
Allocation message to the next node, the 
message includes the source node NSAP 
address, the destination node NSAP 
address, required bandwidth, and identified 
STS-1 slots. Then wait for confirmation 
message from next node. 

Step5: Get the Bandwidth Allocation Confirmation 
message from the next node. 

If YES, modify corresponding resource 
Header Table and associated STS-1 
Status Table to reflect the bandwidth 
allocation. Provision the corresponding 
framer. Respond YES. 



[0049] 

CAP node: 

Step 1 : 



If NO, respond NO. 



For intermediate CIP node and destination 



After receiving Bandwidth Allocation Mes- 
sage from previous node, check whether it 
is the final destination or not. 



w 



20 



25 



35 



The available bandwidth for this link 
exceeds the bandwidth as required 

If there is no such link, Respond NO 
through Bandwidth Allocation Confir- 
mation message. 

Step4: Forward Convergence Protocol Bandwidth 
Allocation message to the next node, the 
message includes the source node NSAP 
address, the destination node NSAP 
address, required bandwidth, the STS-1 No. 
the current node allocated. Then wait for 
confirmation message from next node. 

Step5: Get the confirmation message from next 
node. 

If YES, modify corresponding resource 
Header Table and associated STS-1 
Status Table to reflect the bandwidth 
allocation. Setup corresponding cross- 
connect between STS-1 slots as speci- 
fied by previous node and STS-1 slots it 
allocated, record this information in 
cross-connect table and respond YES. 

If NO, respond NO. 

PROCESS 3: STS-1 level bandwidth de-allocation: 

[0050] For an initiating CAP node: 

Step 1 : Receiving IP destination address. 

Step2: Find corresponding NSAP address of the 
given IP address through Address Binding 
Table. 



If YES, respond YES through Band- 
width Allocation Confirmation message 
to previous node and provision corre- 
sponding STS-1 s as path termination 
so that traffic inside this group of STS- 
1s will be processed by packet switch- 
ing fabric, provision the corresponding 
framer. 

Step2: Otherwise, it's not the final destination. 

Through path table, find out the NSAP 
address of the next, denote it as N. 

Step3: Check the resource Header Table to find out 
the link which satisfies the following condi- 
tions: 

The Neighbor of this link is N 



40 Step3: Find next intermediate node's NSAP 
address based on information obtained 
from The Path Table, Find out STS1s allo- 
cated to reach the corresponding NSAP 
from the resource Header Table and associ- 

45 ated STS-1 Status Table, choose exact No. 

of them based on the given requirement. 

Step4: Send Convergence Protocol Bandwidth De- 
allocation message to the next node, the 
so message includes the source node NSAP 

address, the destination node NSAP 
address, released bandwidth and those 
identified STS-1 slots. 

55 Step5: Modify corresponding resource Header 
Table and associated STS-1 Status Table to 
reflect the bandwidth de-allocation, re-provi- 
sion the framer to de-allocate this group of 
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STS-1 , 

[0051] For an intermediate CIP node and destina- 
tion CAP node: 

Stepl: After receiving Bandwidth De-allocation 
Message from previous node, check 
whether it is the final destination or not. 

If YES, re-provisioning the framer of 
those STS-1 as contained in the incom- 
ing message. Return. 

Step2: Otherwise, it's not the final destination. 

Through path table, find out the NSAP 
address of the next, denote it as N. 

Step3: Based on cross-connect table, find out the 
corresponding STS-1 cross -entry. 

Find the corresponding egress STS-1 
slot entry and delete these cross-con- 
nect provisions. 

Step4: Forward Convergence Protocol Bandwidth 
De-allocation message to the next node, the 
message includes the source node NSAP 
address, the destination node NSAP 
address , the required bandwidth and those 
identified STS-1 slot No. then return. 

[0052] The topology discovery and dynamic band- 
width allocation just desribed may be used to establish 
and end-to-end multi-protocol label switched (MPLS) 
path that provides for minimal blocking. In order to sup- 
port QoS enhanced MPLS, each CAP node should also 
support Label Distribution Protocol (LDP), as described 
in, L. Anderson et al, "LDP Specification, available at 
http://www.letf.org/internet-drafts/draft-ietf-mpls-ldp- 
03.txt, January 1999, and Constrained Routing Label 
Distribution Protocol (CRLDP) as discussed in, 
B.Jamoussi, et al, "Constraint-based LSP Setup Using 
LDP," http://www.letf.org/internet-drafts/draft-ietf-mpls- 
ldp-01 .txt, both of which are hereby incorporated by ref- 
erence in their entirety. In this exemplary embodiment, 
each CAP acts as a Label Switching Router (LSR). If 
one assumes that the CAP is positioned as core (or 
intermediate) LSR, the responsibility of edge LSR con- 
verts the conventional IP header into a label and initi- 
ates the LDP Path setup message. 
[0053] To support explicit routing based traffic engi- 
neering, a CRLDP message is used to explicitly setup a 
Label Switching Path. Based on information advertised 
by each CAR an external router will have clear topology 
information about this virtual autonomous system. Con- 
sequently, the external router is capable of setting a 
path traversing this virtual autonomous system. 
[0054] Beyond best-effort delivery, in order to sup- 



port end-to-end QoS label switching, a system in 
accordance with the principles of the present invention 
sends traffic contract associated with the corresponding 
IP flow along the explicit path. As a result, each node 

5 along the path can decide in advance whether it can 
support or deny the traffic contract request. 
[0055] The process used to set up end-to-end QoS 
based LSP follows. It is assumed that CRLDP is used to 
reserve bandwidth instead of RSVP, since CRLDP is 

w based on hard-state implementation. Since RSVP is 
based on soft-state protocol implementation, periodic 
state-refreshing may consume formidable bandwidth 
and computing, and CRLDP is therefore preferred. 
[0056] Regarding the control path, when an exter- 

15 nal core router receives the IP flow's traffic request, core 
router forwards this request to an adjacent CAP, denot- 
ing it as A,if next node, as indicated in the explicit path, 
is an adjacent CAP Node A then generates the equiva- 
lent bandwidth needed to reach next CAP, based on the 

20 given traffic contract and the Connection Admission 
Control mechanism. Node A then looks up its resource 
table to determine whether existing ports can satisfy 
this request or not. If Yes, Node A reserves the band- 
width and forwards the request to next node. On the 

25 other hand, if Node A's existing ports cannot satisfy the 
request, Node A calculates the closest No. of STS-1 
needed to setup a new port to satisfy this request, then 
determines the internal path (tributary) based on: 

30 (1). Next Node (CAP) information contained in the 

given request 

(2) . Physical path to reach this CAP based on 
Address Binding Table and Path Table 

35 

(3) Based on Process 2 Node A either provisions 
the path to accept this flow or denies this request. If 
this IP flow can be accommodated, the new Con- 
vergence Protocol-based Tunneled CRLDP mes- 

40 sage is sent to next node. 

(4) If the next node is CIP (instead of destination 
CAP), after receiving Convergence Protocol based 
Tunneled CRLDP message, it will get the next node 

45 information based on path table, and forward it to 
next node, until it reaches the next CAP. 

(5) The next CAP terminates the request, calculate 
its egress link, determines whether it can support it 

so or not. If not, sends "No" back to entry CAP through 
Tunneled CRLDP message Otherwise, forward 
request to next node (router/CAP), if any, and wait 
for the response. 

55 (6) After the next CAP gets the response (assuming 
positive, otherwise, forward NO back to the entry 
CAP) which includes the egress label, allocates its 
own ingress label for this IP flow, forward it to entry 
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CAP through Tunneled CRLDP message including 
the label it allocated. 

(7) After source CAP gets the response which 
includes the egress label allocated by destination 5 
CAP, allocates its own ingress label for this IP flow, 
forward it to the external core router. 

[0057] Through the above control-message 
exchange, a system in accordance with the principles of 
the present invention sets up the LSP for the incoming 
IP flow traversing transport core. After establishing the 
LSP, the data flow is as follows. 



channel/tributary via label exact matching, swaps 
the ingress label into egress label and sends the 
flow to next LSR. 

[0058] Using this approach provides a flexible, 35 
bandwidth-adaptive backbone. Additionally, minimal 
end-to-end latency is needed, since only the entry CAP 
and exit CAP involve layer 2 label swapping and related 
packet flow queuing. Additionally, in the intermediate 
CIPs, layer-1 pass-through gives the minimal (determin- 40 
istic) traversing latency. 

[0059] In accordance with the principles of the 
invention, a bandwidth-on-demand SONET/SDH trans- 
port infrastructure may be effected using the new con- 
vergence protocol as set forth below. 45 
[0060] In one illustrative embodiment, one which 
employs a centralized resource management approach, 
a network management system triggers bandwidth allo- 
cation. During the path-setup period, it sends the follow- 
ing information to the initiating node (only): the so 
destination address and required bandwidth. Then Con- 
vergence Protocol is used to exchange bandwidth infor- 
mation among nodes along the path. Processes 2 and 
3, as described above, can be used to support this 
approach. 55 

Step 1 : NMS sends physical path provisioning infor- 
mation to ATM/IP side of CAP S1, which includes 



the following information: (assuming through GUI 
interface) 

Management ATM/IP address of CAP S2 

Bandwidth required: in this example, assuming 
OC-3C 



Logical port provisioning information (for both 
ends) 

ATM/IP address information (for both ends) 

Routing information provisioning (for IP case, 
OSPF/RIP/BGP, for ATM case, OPSF/PNNI) 

Step 2: ATM/IP side of CAP S1 finds corresponding 
management NSAP address of CAP S2 through 
looking up its address-binding table based on given 
ATM/IP management address information of CAP 
S2. 

If corresponding management NSAP address 
of CAP S2 can't be found, negative response is 
sent back to NMS. Otherwise, proceeds to Step 
3. 

Step 3: ATM/IP side of CAP S1 forwards provision- 
ing information to its SONET side, which includes 
bandwidth requirement information and manage- 
ment NSAP address of CAP S2 

Step 4: SONET side of CAP S1 first determines 
whether inter-connect bandwidth inside CAP is suf- 
ficient to satisfy this requirement. If not, it sends 
negative response back to ATM/IP side of CAP S1 , 
and then this negative response is further for- 
warded to NMS. 

Step 5: If inter-connect bandwidth can accommo- 
date this, based on established SONET topology, 
SONET side of CAP S1 finds out the path to reach 
SONET side of CAP S2, it also finds out its egress 
ports it can use to reach CAP S2. If it can't, it sends 
negative response back to ATM/IP side of CAP S1 , 
and then this negative response is further for- 
warded to NMS. 

Step 6. Then SONET side of CAP S1 determines 
that for any of identified egress port, whether 
egress port bandwidth is sufficient to satisfy this 
requirement. If not, it sends negative response 
back to ATM/IP side of CAP S1, and then this 
response is further forwarded to NMS. 



Logical link layer provisioning information (in IP 
w case, Frame-relay or PPP provisioning infor- 

mation) for both ends 



(1) The packet of this IP flow is sent to entry CAP 15 
(denoting it as A) from the core router. 

(2) Based on label exact matching, node A finds the 
corresponding internal channel/tributary to be 
used, swaps the ingress label into the egress label, 20 
and, if the next node is a CIP, Node A forwards the 
packet to next node. 

(3) An intermediate SONET node passes the 
packet through this internal channel via the cross- 25 
connect fabric. This internal channel is a SONET 
path based on a cross-connect fabric that is estab- 
lished via the new convergence protocol signalling. 

(4) The destination CAP terminates the internal 30 
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Step 7: If its egress port bandwidth can accommo- 
date this requirement, based on identified path 
information, SONET side of CAP SI reserves cer- 
tain STS-1 slots and initiates the signaling message 
flow and sends it to next node and waits for 
response from next node. The message includes 
path information and reserved STS-1 slots informa- 
tion. 

(Assuming source/explicit routing is used) 

Step 8: If response received from next node is pos- 
itive, SONET side of CAP S1 provisions corre- 
sponding cross-connects, and sends physical 
provisioning information through proprietary signal- 
ing to ATM/IP side of CAP S1. Then ATM/IP side 
will provision corresponding tributary, including 
physical layer, logic link layer and ATM/IP layer, 
then initiates routing stack. Then positive response 
is sent back to NMS (Navis in this case). 

If response received from next node is nega- 
tive, SONET side of CAP S1 cancels STS-1 
slot reservation, then sends negative response 
back to ATM/IP side of CAP S1, and then this 
negative response is further forwarded to NMS. 

[0061] Using a distributed resource management 
approach, each CAP node has the up-to-date transport 
network topology and each CAP collects the perform- 
ance monitoring information. Based on the above infor- 
mation, it makes a decision by itself as to whether a 
link's bandwidth should be adjusted. Each CAP also 
establishes the path based on routing table-lookup; 
makes the decision to re-adjust the bandwidth for each 
established tributary based on performance monitoring, 
and exchanges the bandwidth allocation/de-allocation 
information with other nodes along the path through 
Convergence Protocol Processes 2 and 3, as described 
above. Referring to Figure 12, the system 1200 includes 
a network management system 1202, first and second 
users 1 204 and 1 206 that are respectively connected to 
ATM/IP networks 1208 and 1210. Routers R1 through 
R4 connect users 1204 and 1206 through the ATM/IP 
networks 1208 and 1210 to CAPs 1212 and 1214, 
respectively which provide access to the transport facil- 
ities of the SONET/SDH system 1216. 
[0062] Such a bandwidth allocation process will be 
described below with reference to the scenario diagram 
of Figure 13 in which: 

Step 1 : NMS sends physical path provisioning infor- 
mation to ATM/IP side of CAP1, which 
includes the following information: (assum- 
ing through GUI interface) 

Management ATM/IP address of CAP2 



Bandwidth required: in this example, 
assuming OC-3C 

Logical link layer provisioning informa- 
5 tion (in IP case, Frame-relay or PPP 

provisioning information) for both ends 

Logical port provisioning information 
(for both ends) 

10 

ATM/IP address information (for both 
ends) 

Routing information provisioning (for IP 
15 case, OSPF/RIP/BGR for ATM case, 

OPSF/PNNI) 

Step 2: ATM/IP side of CAP1 finds corresponding 
management NSAP address of CAP S2 
20 through looking up its address-binding table 

based on given ATM/IP management 
address information of CAP2. 

If corresponding management NSAP 
25 address of CAP2 can't be found, nega- 

tive response is sent back to NMS. Oth- 
erwise, proceeds to Step 3. 

Step 3: ATM/IP side of CAP1 forwards provisioning 
30 information to its SONET side, which 

includes bandwidth requirement information 
and management NSAP address of CAP2 

Step 4: SONET side of CAP1 first determines 
35 whether inter-connect bandwidth inside 

CAP is sufficient to satisfy this requirement. 
If not, it sends negative response back to 
ATM/IP side of CAP 1, and then this nega- 
tive response is further forwarded to NMS. 

40 

Step 5: If inter-connect bandwidth can accommo- 
date this, based on established SONET 
topology, SONET side of CAP1 finds out the 
path to reach SONET side of CAP2, it also 
45 finds out its egress ports it can use to reach 

CAP2. If it can't, it sends negative response 
back to ATM/IP side of CAP1 , and then this 
negative response is further forwarded to 
NMS. 

50 

Step 6. Then SONET side of CAP1 determines that 
for any of identified egress port, whether 
egress port bandwidth is sufficient to satisfy 
this requirement. If not, it sends negative 
55 response back to ATM/IP side of CAP1 , and 

then this response is further forwarded to 
NMS. 
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Step 7: If its egress port bandwidth can accommo- 
date this requirement, based on identified 
path information, SONET side of CAP1 
reserves certain STS-1 slots and initiates 
the signaling message flow and sends it to 
next node and waits for response from next 
node. The message includes path informa- 
tion and reserved STS-1 slots information. 

(Assuming source/explicit routing is 
used) 

Step 8: If response received from next node is posi- 
tive, SONET side of CAP1 provisions corre- 
sponding cross-connects, and sends 
physical provisioning information through 
proprietary signaling to ATM/IP side of 
CAP1. Then ATM/IP side will provision cor- 
responding tributary, including physical 
layer, logic link layer and ATM/IP layer, then 
initiates routing stack. Then positive 
response is sent back to NMS (Navis in this 
case). 

[0063] If response received from next node is nega- 
tive, SONET side of CAP1 cancels STS-1 slot reserva- 
tion, then sends negative response back to ATM/IP side 
of CAP1 , and then this negative response is further for- 
warded to NMS in steps 9 through 1 1 . 
[0064] In another illustrative embodiment in accord- 
ance with the principles of the present invention, net- 
work employs protocol-driven resource management. 
With this approach, a bandwidth reservation protocol 
such as CRLDP or RSVP etc. may be used to trigger 
bandwidth allocation. As previously described, these 
protocols embody implicit bandwidth requirement (to 
support the corresponding QoS) and explicit path infor- 
mation. Based on a Connection Admission Control 
algorithm, the entry CAP node will convert the implicit 
bandwidth requirement into equivalent bandwidth, then 
exchange bandwidth allocation/de-allocation informa- 
tion with other nodes along the path as indicated in the 
incoming protocol message. 

[0065] The flowchart of Figure 14 illustrates the 
process of initializing, establishing a CAP path and 
dynamically allocating bandwidth in accordance with 
the principles of the present invention. The de-allocation 
of bandwidth in accordance with the principles of the 
present invention is also illustrated in the flowchart. In 
step 1400 the process begins and proceeds to step 
1402 where nodes employing the convergence protocol 
are initialized. The initialization includes the running of 
both OSI stack and TCP/IP stack in CAPs and the run- 
ning of OSI stack in CIPs. The process proceeds from 
step 1402 to step 1404 where network nodes follow a 
process of auto-discovery as previously described in 
greater detail in the above section entitled, "IS-IS based 
topology auto-discovery". Following step 1404 the proc- 



ess proceeds to step 1406 where each CAP pair estab- 
lishes a logical path between themselves. This logical 
path establishment may entail the flooding of a CAP'S I P 
address information to other CAPs employing a label 

5 switched path variable length field. The logical path 
establishment process is described in greater detail in 
the above section entitled "CAP path establishment". 
[0066] From step 1406 the process proceeds to 
step 1408 where a receiving node responds to the 

w reception of a IS-IS label switched path message in 
accordance with the principles of the present invention 
by treating it in a conventional manner if the receiving 
node is a CI P. A CAP will, additionally, refresh its routing 
table, based on the incoming information. This process 

15 is discussed in greater detail in relation to Figure 7. 
From step 1408 the process proceeds to step 1410 
where a CAP establishes an address binding table and 
obtains the path information necessary to reach other 
CAPs. This process is discussed in greater detail in 

20 relation to "Process 1", described above. From step 
1 41 0 the process proceeds to step 1 41 2 where a node 
passes a convergence protocol bandwidth allocation 
message node to node until it reaches the destination 
CAP. In step 1414 the bandwidth along the path is allo- 
cs cated, if available. The processes of steps 1412 and 
1414 are described in greater detail in the discussion of 
"Process 2", described above. At some point there may 
be a need for bandwidth de-allocation and, in that case, 
the process would proceed to step 1416 where a node 

30 passes a convergence protocol bandwidth de-allocation 
message, node to node, until the destination CAP is 
reached. In step 1418 the bandwidth is de-allocated, as 
appropriate. The processes of steps 1 41 6 and 1 41 8 are 
described in greater detail in the discussion of "Process 

35 3", described above. The overall process may proceed 
to END in step 1420, for example, during maintenance 
or installation operations, for example. 
[0067] The foregoing description of specific embod- 
iments of the invention has been presented for the pur- 

40 poses of illustration and description. It is not intended to 
be exhaustive or to limit the invention to the precise 
forms disclosed, and many modifications and variations 
are possible in light of the above teachings. The embod- 
iments were chosen and described to best explain the 

45 principles of the invention and its practical application, 
and to thereby enable others skilled in the art to best uti- 
lize the invention. It is intended that the scope of the 
invention be limited only by the claims appended hereto. 



so Claims 

1 . A telecommunications system comprising: 

a first network element which conforms to an 
55 OSI seven layer model; and 

a second network element which conforms to 
an OSI seven layer model, each of the ele- 
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merits employing a convergence protocol 
whereby one of the layers of one of the network 
elements may communicate directly with a dif- 
ferent layer of the other network element. 

2. The system of claim 1 wherein the convergence 
protocol allows the transport layer of one network 
element to communicate directly with the service 
layer of another network element. 

3. The system of claim 2 wherein the service layer is 
an internet protocol service layer. 

4. The system of claim 2 wherein the transport layer is 
a synchronous optical network (SONET) transport 
layer. 

5. The system of claim 2 further comprising a plurality 
of packet-switched devices and wherein said first 
and second network elements are connected to 
provide circuit-switched cross-connect for the 
packet switched devices. 

6. The system of claim 5 wherein at least one of the 
packet-switched devices is an Internet protocol (IP) 
device. 

7. The system of claim 5 wherein at least one of the 
packet-switched devices is an asynchronous trans- 
fer mode (ATM) device. 

8. The system of claim 4 wherein a network element is 
responsive to a request from another network ele- 
ment using the convergence protocol for bandwidth 
along a link by granting bandwidth to the requesting 
network element. 

9. The system of claim 8 wherein the request from one 
network element for bandwidth from another net- 
work element is effected via inter-layer, inter-ele- 
ment communications in a direct communications 
channel. 

10. The system of claim 9 wherein a network element 
monitors layer three and layer one operations. 

11. In a telecommunications system including packet- 
switched and circuit-switched network elements, a 
method comprising the steps of: 

(A) sending a message from one network ele- 
ment at one network layer; and 

(B) receiving the message of step (A) at a dif- 
ferent network layer in a different network ele- 
ment. 

12. The method of claim 1 1 wherein step (A) comprises 



the step of: 

(A1) communicating directly from the transport 
layer of one network element with the service 
5 layer of another network element. 

13. The method of claim 12 wherein the service layer is 
an internet protocol service layer. 

w 1 4. The method of claim 1 2 wherein the transport layer 
is a synchronous optical network (SONET) trans- 
port layer. 

15. The method of claim 11 further comprising the step 
15 of: 

(C) providing circuit switched cross-connection 
for a plurality of packet-switched devices. 

20 16. The method of claim 15 wherein step (C) comprises 
the step of: 

(C1) providing circuit switched cross-connec- 
tion for an Internet protocol (IP) device. 

25 

1 7. The method of claim 1 5 wherein step (C) comprises 
the step of: 

(C2) providing circuit switched cross-con nec- 
30 tion for an asynchronous transfer mode (ATM) 

device. 

18. The method of claim 12 further comprising the 
steps of: 

35 

(D) sending a request from one network ele- 
ment to another for additional bandwidth; and 

(E) granting additional bandwidth to a network 
40 element that requests additional bandwidth. 

1 9. The method of claim 1 8 wherein step (D) is effected 
via inter-layer, inter-element communications in a 
direct communications channel. 

45 

20. The method of claim 1 9 further comprising the step 
of: 

(F) a network element monitoring layer three 
so and layer one operations; and 

(G) the network element of step (F) adjusting 
the bandwidth of a logical pipe in response to 
changes in layer three and layer one opera- 

55 tions. 

21. A method of establishing communications paths in 
a hybrid, circuit-switched/packet- switched telecom- 
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munications system comprising the steps of: (H) a destination CAP'S de-allocation of band- 

width in response to the reception of conver- 

(A) initializing nodes that provide an interface gence protocol de-allocation message, 
between SONET/SDH transport and external 

IP transport, by running both OSI stack and 5 
TCP/IP stack; 

(B) initializing SONET/SDH network elements 
that are digital cross-connect, by running OSI 
stack; and 10 

(C) auto-discovering the network topology 
using intermediate system-intermediate sys- 
tem (IS-IS) adjacency relationships. 

15 

22. The method of claim 21 wherein step (C) further 
comprises the step of: 

(D) establishing the physical topology of each 
node within the telecommunications system 20 
based on the exchange of IS-IS Link State Pro- 
tocol Data Units. 

23. The method of claim 21 further comprising the step 

of: 25 

(E) establishing a logical path between a pair of 
CAPs. 

24. The method of claim 23 wherein step (E) further 30 
comprises the step of: 

(E1) the refreshing of a routing table by a CAP 
in response to the reception of a IS-IS label 
switched path message. 35 

25. The method of claim 24 wherein step (E) further 
comprises the step of: 

(E2) a CAP'S establishment of an address bind- 40 
ing table and determining the path information 
required to reach another CAP. 

26. The method of claim 23 further comprising the step 

of: 45 

(F) passing a convergence protocol bandwidth 
allocation message to a destination CAP. 

27. The method of claim 26 further comprising the step 50 
of: 

(G) a destination CAP's allocation of bandwidth 
in response to the reception of a bandwidth 
allocation message as in step (F). 55 

28. The method of claim 27 further comprising the step 
of: 
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